Claiming: sign in with a passkey, publish a token, be verified - #16

* Claiming was complete, tested, and wired to nothing

§8.5 says nothing sets game.is_claimed, so the listing badge and §7.5's ceiling
grace have never been exercised. Claiming shipped in #16 and the note still read
true, so I went looking for why. The claim logic was not the problem — it is
complete and it has tests. The composition was.

The site has two compositions of the same objects. mui-crawl builds the crawl
loop by hand and passes every collaborator; the deployed site assembles it
through DI. Three things were wrong with the second, and none of them could fail
loudly:

CrawlCycle takes its ClaimService as an OPTIONAL parameter, deliberately — a
crawl with no database should do slightly less rather than refuse to run. The
crawler graph registered no ClaimService, so a crawler-only deployment settled
no beacons and said nothing about it.

ClaimService was registered scoped, and the crawl loop that needs it is a
singleton BackgroundService. A scoped dependency is one CrawlCycle can never
legally be given: with scope validation on, which is what `dotnet run` does, the
container refuses to build and THE SITE DOES NOT START with a connection string
set. Production leaves validation off, so there it worked — by accident, and
only there. That is also the answer to §8.5's note: is_claimed was being set in
production and nowhere else.

IClaimStore was registered nowhere at all. Account.razor service-locates it and
reads a null as "this site has no database", so every operator's dashboard was
empty on a site that had their claims, and /g/{slug}/claim/check threw on
request. A service-located dependency fails silently by construction.

Both services are stateless over a pooled NpgsqlDataSource, so both are now
TryAddSingleton, registered by the crawler graph and the accounts graph alike —
the one deployment that runs both gets one of each.

CompositionTests resolves the graph Program builds, under scope validation, in
both environments, and asserts the claim path is really joined. It fails on the
parent commit in seven ways and is the only kind of test that could have caught
any of this: every part was correct and the wiring between them was not.

§8.5's closing note is rewritten to say what is actually true, and to name the
general hazard — an optional dependency and a service-located one both fail
silently when the composition is wrong, and the claim path has one of each.

830 tests over five suites, Postgres exercised. Testcontainers 4.13.0 -> 4.14.0
is the same one-line pickup as #26: SSH.NET 2025.1.0 is now advised against and
NU1903 fails restore on main without it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Compose the test from Program's own graph, and make "look sooner" look

Review findings on the composition fix. All four held; each is verified rather
than taken.

CompositionTests restated Program's registrations instead of running them, so a
future divergence — a scoped service consumed by a singleton, AddMuiAccounts
moving — would break the site while all the tests passed. That is exactly the
failure this file exists to catch. The graph moves out of Program's top-level
statements into SiteComposition.AddMuiSite/UseMuiSite, which the deployable and
the test now both call, so there is one copy and nothing to diverge from.

The on-demand check moved nothing. RequestCheckAsync wrote last_checked_at and a
check_requested event; due-ness comes only from crawl_target.next_probe_at, so
no probe ever came of it while the page said the button dialled a real server. A
rate limiter on an action that does not happen is the most convincing possible
no-op. IOnDemandProbes brings the game's targets forward with LEAST — an ask can
only make a probe sooner — and the crawl loop still does the dialling under
CRAWL DELAY and §7.2's address gate. Five Postgres tests assert on the schedule
rather than on the audit log. The button now says what it does: "Look sooner",
brings your game to the front of the queue, we dial on our own schedule.

The remark on TheHostedCrawlerCanBeResolvedInProductionToo described a failure
that never happened — it passes on the parent commit, because Production leaves
scope validation off and resolved the scoped ClaimService from the root. It is a
control, not a finding, and now says so. Measured: the original seven tests fail
five ways on the parent, not seven. With the four added here, ten fail seven.

"A crawler-only deployment" justified the new registrations in three places and
describes nothing: AddMuiCrawler has exactly one caller, MUI.Web's Program, and
mui-crawl builds its graph by hand. §4.11 has one deployable. The real consumer
is the web tier's in-process CrawlCycle, and all three now say so.

Two more while here. The demo composition had no test at all; it has one, and it
asserts the claim surfaces are absent rather than broken and that the page still
admits nothing on it was measured. And the web tier registered its own
NpgsqlAvailabilityStore with AddSingleton, so the crawler's TryAdd was skipped
and the concrete type and IReachableHistory pointed at a second instance —
harmless on one pool and a direct contradiction of the crawler's own comment
that two would be two connection paths answering one question. AddPostgresCatalogue
is TryAdd throughout now, and one object answers to all three names.

838 tests over five suites, Postgres exercised.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Drive the passkey ceremony for real, because nothing ever had

#30 reported that a JSON POST to a minimal API mapped after UseAntiforgery() is
refused with 400 in a slim host, even with .DisableAntiforgery(), which would
mean passkey sign-in is broken and §8.2 leaves no other way in.

IT DOES NOT REPRODUCE. Measured against the real host — accounts registered,
Postgres behind them, migrations applied, ASPNETCORE_ENVIRONMENT=Production:

  POST /account/passkey/assertion-options     -> 200
  POST /account/passkey/sign-in  (as sent)    -> 401
  POST /account/passkey/registration-options  -> 200
  POST /account  (Razor route, no token)      -> 400   <- control

The control is the part that makes the rest mean anything: anti-forgery IS live
in that pipeline and refuses an untokened POST one route over. The 401 is the
handler answering, not the middleware — the first attempt without the ceremony's
cookie got a 500 from SignInManager saying no assertion was underway, which is
the handler too.

The mechanism: a minimal API is given anti-forgery metadata only when it binds
FORM data. These bind JSON or a query string, so they carry none and the
middleware passes them through; MapRazorComponents puts metadata on component
routes, which is why the control is refused. And .DisableAntiforgery() sets
RequiresValidation false — a 400 surviving it was never anti-forgery's.

Adding the test anyway. Sign-in is the only door in the building and no suite
opened it: the ones that exercise sign-in are the ones that stub it, and the
composition tests stop at the graph. These drive the real routes through
AddMuiSite/UseMuiSite, with a control that fails if anti-forgery ever stops
being live and would catch the reported failure if it ever became real.

841 tests over five suites, Postgres exercised.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>